The precision of the cycle counter depends on the hardware system. In the Challenge/Onyx line it is a 64-bit integer. The frequency that it counts also varies with the system. In the Challenge/Onyx, it is 21 nanoseconds (47.6 MHz).
You obtain the size fo the cycle counter in bytes (4 or 8) using syssgi(SGI_CYCLECNTR_SIZE). You obtain the address of the cycle counter (in the kernel's virtual address space) using syssgi(SGI_QUERY_CYCLECNTR), a call that also returns the counter precision in picoseconds (1e-12 seconds, millionths of a microsecond). See the syssgi(2) reference page for details. As can be seen from an example program ("Mapping and Reading the Cycle Counter"), this method of reading the cycle counter is somewhat complex since it has to take into account two variables: the precision of the clock in the current system, and the programming model of the compiled program (32-bit or 64-bit).
You can also interrogate the cycle counter value, converted to a timespec_t form, using the clock_gettime() function (see clock_gettime(2) for use of the nonstandard CLOCK_SGI_CYCLE option). The first time this function is used, maps the cycle counter into the process address space. After that, each call merely fetches the hardware value and formats it into the fields of a timespec_t structure. By using clock_gettime() you eliminate the complexity of syssgi() and mmap() calls, and the function is portable to all current Silicon Graphics, Inc. systems.
Since the update frequency of the cycle counter is close to the maximum CPU instruction rate, it is not possible to read the same value from it twice.
However, the cycle counter is simply a free-running hardware device; it is not synchronized with any corrected time base. Its drift rate can be as high as 1 part in 10,000--100 microseconds per second, or approximately 8 seconds per day.